ATTORNEY'S DOCKET: 
020431.0934 



11 



PATENT APPLICATION 
USSN 10/001,506 



Remarks 

This Application has been carefully reviewed in light of the Final Office Action dated 
November 3, 2004. Although Applicant believes all pending claims are allowable without 
amendment, Applicant has made clarifying amendments to independent Claims 1, 12, 20, and 
28, and to dependent Claims 5, 7-8, 16, 18, 24, 26, 29-30, 34-35, and 41-42. At least certain 
of these amendments are not considered narrowing or necessary for patentability. These 
amendments place the Application in better form for Appeal and do not require a new search. 
Applicant therefore respectfully requests that the Examiner enter these amendments. 
Applicant respectfully requests reconsideration and allowance of all pending claims. 

I. The Claims are Allowable over Oracle 

The Examiner rejects Claims 1-4, 6, 8, 10-15, 19-23, 27-28, 31-33, and 36-40 under 
35 U.S.C. § 102(b) as being anticipated by Oracle EDI - Oracle© e-Commerce Gateway, 
User's Guide, Release lli.2, August 2000 (^Oracle"). Applicant respectfully disagrees and 
discusses Claim 1 as an example. 

Oracle discloses an e-commerce gateway designed for integration with trading 
partners and/or EDI translators and for providing an application-to-application integration 
solution. The gateway is a file-based integration layer between Oracle applications and other 
external applications. Transaction data originating from an external trading partner is 
formatted and transmitted to the receiving trading partner. Once received, the data may go 
through another formatting process (e.g., an EDI translator) resulting in an interface data file 
based on the standard layout defined in the gateway. The gateway then processes the 
interface data file and passes the data to the receiving application for additional business rule 
validation and transaction creation. (Page 1-3) 

For inbound transactions, the gateway receives a file from a source in the standard 
transaction interface data file format defined in the gateway. The gateway then processes the 
data by first validating the trading partner that sent the transaction against trading partners 
defined in the gateway. The gateway then processes any enabled code conversion, process 
rules, and column rules. Transactions that pass process and column rules are mapped and 
written to specified Oracle applications open interface tables for application-specific business 
rule validation. (Page 1-3) 
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For outbound transactions, a user-defined event or an application event signals the 
gateway to begin the outbound process. The gateway extracts data from the application 
transaction tables and verifies that the receiving trading partner is authorized to receive the 
transaction. Code conversion rules are applied to the data, and the data is mapped and written 
to the transaction interface data file. The format of this file is based on the standard file 
layout defined in the gateway. (Page 1-4) 

As the above summary (and the balance of the Oracle reference) makes clear, Oracle 
merely discloses a gateway that: (1) defines trading partner groups and trading partner 
locations; (2) enables transactions for trading partners; (3) provides general code conversion 
between trading partner codes or standard codes and the codes defined in Oracle applications; 
(4) defines interface data files so that applications can integrate with trading partners' 
applications or EDI translators; (5) for inbound transactions, imports data into application 
open interface tables so that application program interfaces can validate and update Oracle 
application tables; and (6) for outbound transactions, extracts, formats, and writes application 
data to interface data files. {See Page 1-2) 

However, Oracle fails to disclose, teach, or suggest various limitations recited in 
Claim 1. 

For example, Oracle fails to disclose, teach, or suggest "an intelligence module 
operable to, in response to selection of a transaction document [which are associated with a 
past transaction] by a party who was not a party to the past transaction associated with the 
transaction document, create a generic document capable of being used to facilitate a future 
transaction with at least one of the sellers from the selected transaction document stored in 
the one or more document repositories, the generic document created from the selected 
transaction document comprising the selected transaction document with selected information 
in the selected transaction document made inaccessible in the generic document," as recited 
in Claim 1 as amended. 1 

1 Certain of the amendments to independent Claim 1 (as well as to other claims) involve amending the phrase 
"one or more" to the term "a" or "the." Applicant notes that these amendments are not considered narrowing 
and are made for clarification purposes only. It is well established that the term "a" means "one or more," and 
Applicant does not intend to depart from that well-established rule. See, e.g., KCJ Corp. v. Kinetic Concepts, 
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In concluding that Oracle purportedly discloses this claim element (as it was recited 
in Claim 1 prior to the amendments presented in this Response), the Examiner states, 
"OraEDTs e-commerce gateway is the intelligence module by which [a] data file for [a] 
shipping notice inbound transaction is imported into [the] database and the payment 
remittance is created in the outbound transaction where the information of [the] shipping note 
is different from the payment remittance is equivalent to" the above-recited element of Claim 
1. {See Office Action, Page 4) As best as Applicant can determine from the Examiner's 
explanation, the Examiner attempts to equate the shipping notice disclosed in Oracle with the 
one or more transaction documents recited in Claim 1 and the payment remittance disclosed 
in Oracle with the one or more generic documents recited in Claim 1 . Applicant respectfully 
submits that Oracle does not support this interpretation. 

First, the payment remittance (which the Examiner equates with the one or more 
generic documents recited in Claim 1) is not generic at all. Instead, it is clearly specific to the 
transaction for which the shipping notice was received. For example, suppose that a shipping 
notice is received for the shipment of product A from supplier X. The payment remittance 
generated in response to the shipping notice would also be for product A from supplier X - 
the same transaction. Thus, there is nothing generic about the generated payment remittance 
generated by the system disclosed in the Oracle, and Applicants respectfully submit that the 
Examiner's position to the contrary are unsupportable. 

Second, even assuming that the payment remittance disclosed in Oracle (which the 
Examiner equates with the one or more generic documents recited in Claim 1) was generic 
(which it is not), it is not even clear that the payment remittance is created from the shipping 
notice (which the Examiner equates with the one or more transaction documents recited in 
Claim 1). Thus, Oracle clearly fails to disclose, teach, or suggest "an intelligence module 
operable to create a generic document . . .from the selected transaction document stored in 
the one or more document repositories, the generic document created from the selected 
transaction document comprising the selected transaction document with selected information 



Inc., 223 F.3d 1351, 1356 (Fed. Cir. 2000) (stating that "[u]nless the claim is specific as to the number of 
elements, the article 'a' receives a singular interpretation only in rare circumstances when the patentee evinces a 
clear intent to so limit the article."). 
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in the selected transaction document made inaccessible in the generic document," as recited 
in Claim 1 as amended. 

Third, Oracle fails to disclose, teach, or suggest that "the generic document created 
from the selected transaction document comprisfesj the selected transaction document with 
selected information in the selected transaction document made inaccessible in the generic 
document" as recited in Claim 1 as amended. To use the Examiner's attempted analogy 
between Oracle and the limitations recited in Claim 1, the payment remittance disclosed in 
Oracle (which the Examiner equates with the one or more generic documents previously 
recited in Claim 1) purportedly created from the shipping notice disclosed in Oracle (which 
the Examiner equates with the transaction documents recited in Claim 1) does not comprise 
the shipping notice with selected information in the shipping notice made inaccessible in the 
payment remittance. The fact that the shipping notice in Oracle is different from the payment 
remittance in Oracle, as stated by the Examiner {see Final Office Action, Page 4), has no 
bearing on the limitations recited in Claim 1, since it is not even clear that the payment 
remittance is created from the shipping notice. The payment remittance does not in any way 
comprise the shipping notice with selected information in the shipping made inaccessible. 
Thus, Oracle clearly fails to disclose, teach, or suggest "the generic document created from 
the selected transaction document comprising the selected transaction document with 
selected information in the selected transaction document made inaccessible in the generic 
document" as recited in Claim 1 as amended. 

"A claim is anticipated only if each and every element as set forth in the claim is 
found, either expressly or inherently described, in a single prior art reference." Verdegaal 
Bros. v. Union Oil Co. of California, 814 F.2d 628, 631, 2 U.S.P.Q.2d 1051, 1053 (Fed. Cir. 
1987) (emphasis added); M.P.E.P. § 2131. In addition, "[t]he identical invention must be 
shown in as complete detail as contained in the . . . claim." Richardson v. Suzuki Motor Co., 
868 F.2d 1226, 1236, 9 U.S.P.Q.2d 1913, 1920 (Fed. Cir. 1989) (emphasis added); see also 
M.P.E.P. § 2131. Furthermore, "[t]he elements must be arranged as in the claim under 
review." In re Bond, 910 F.2d 831, 832, 15 U.S.P.Q.2d 1566, 1567 (Fed. Cir. 1990); 
M.P.E.P. § 2131. The distinctions discussed above clearly illustrate that Oracle fails to 
disclose, either expressly or inherently, each and every limitation recited in Applicant's 
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Claim 1, as is required under the M.P.E.P. and governing Federal Circuit cases. For this 
reason alone, the anticipation rejections based on Oracle are inappropriate. 

For at least these reasons, independent Claim 1 and its dependent claims are allowable 
over Oracle. For at least analogous reasons, independent Claims 12, 20, and 28 and their 
dependent claims are allowable over Oracle. Applicant respectfully requests reconsideration 
and allowance of independent Claims 1, 12, 20, and 28 and their dependent claims. 

II. The Rejected Dependent Claims are Allowable over the Proposed Oracle-Keller 
Combination 

The Examiner rejects Claims 5, 7, 9, 16-18, 24-26, 29-30, 34-35, and 41-42 under 35 
U.S.C. § 103(a) as being unpatentable over Oracle in view of U.S. Publication 2003/0050958 
to Keller, et al. ("Keller"). 2 Applicant respectfully disagrees. 

Claims 5, 7, 9, and 29-30 (which depend from independent Claim 1), Claims 16-18 
and 34-35 (which depend from independent Claim 12), and Claims 24-26 and 41-42 (which 
depend from independent Claim 20) depend from independent Claims 1, 12, and 20, which 
Applicant has shown above to be clearly allowable over Oracle. As discussed in the previous 
Response and as acknowledged by the Examiner in the Final Office Action {see Page 11), 
Keller fails to make up for the deficiencies of Oracle with respect to the independent claims. 
Additionally, Applicant does not admit that it is technologically possible to combine Oracle 
with Keller in the manner proposed by the Examiner or that the Examiner has shown the 
requisite teaching, suggestion, or motivation in these references to combine these references 
in the manner proposed by the Examiner. Claims 5, 7, 9, 16-18, 24-26, 29-30, 34-35, and 41- 
42 are allowable for at least these reasons. Furthermore, Claims 5, 7, 9, 16-18, 24-26, 29-30, 
34-35, and 41-42 recite further patentable distinctions over the proposed Oracle-Keller 
combination. 



2 As stated in the previous Response, Applicant reiterates his belief that he could antedate Keller based at least 
on Applicant's date of conception prior to September 10, 2001 (the filing date of Keller) and subsequent 
diligence up to the October 23, 2001 filing date of the Application. While Applicant has chosen not to do so in 
the present Response due to the clear distinctions between Applicant's independent claims and Oracle (as well 
as Keller, as discussed in the previous Response), Applicant reserves the right to antedate Keller in a future 
Response or on Appeal, if appropriate. By not antedating Keller at this time, Applicant does not concede that 
Keller qualifies as prior art. 
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For example, dependent Claim 5, as amended, recites that the intelligence module: 

• segments the selected transaction document into one or more sections; 

• determines which sections of the selected transaction document are 
generic and which sections are specific to the past transaction; 

• removes from the selected transaction document information in the 
sections specific to the past transaction to create the generic document 
capable of being used to facilitate the future transaction; and 

• carries forward the generic sections from the selected transaction 
document into the generic document to protect one or more confidential 
details in the selected transaction document. 

Dependent Claims 16 and 24 recite analogous limitations. Applicant respectfully submits 
that the proposed Oracle-Keller combination fails to disclose, teach, or suggest these . 
limitations. 

First, the proposed Oracle-Keller combination fails to disclose, teach, or suggest an 
intelligence module that "determines which sections of the selected transaction document are 
generic and which sections are specific to the past transaction," as recited in Claim 5 as 
amended. The Examiner argues that Oracle discloses these limitations, referring to Oracle's 
disclosure that a selected level of data within a transaction defined by the system disclosed in 
Oracle may differ when compared to the base application tables as data is denormalized. {See 
Oracle, Page 5-3 and Office Action, Page 8) However, this disclosure in Oracle in no way 
discloses, teaches, or suggests an intelligence module that "determines which sections of the 
selected transaction document are generic and which sections are specific to the past 
transaction" as recited in Claim 5 as amended. 

Keller fails to make up for these deficiencies of Oracle. 

Second, the proposed Oracle-Keller combination fails to disclose, teach, or suggest an 
intelligence module that "removes from the selected transaction document information in the 
sections specific to the past transaction to create the generic document capable of being used 
to facilitate the future transaction," as recited in Claim 5 as amended. The Examiner argues 
that Oracle discloses these limitations, relying on Page 7-3 of Oracle. In particular, the 
Examiner states that Oracle discloses that "invoice data is deleted from Open Interface tables 
after invoice data is imported to Payables." (See Office Action, Page 8) According to Oracle, 
the Payables Open Interface is used to import supplier invoices into the Oracle Payables 
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system. Oracle discloses that a parameter may be selected to "delete the invoice data from 
the Payables Open Interface tables after the data has been imported into Oracle Payables." 
(Page 7-3) Thus, it appears to Applicant that the system disclosed in Oracle merely deletes 
information that is imported from the Payable Open Interface tables used to import that 
information into Oracle Payables. This disclosure in Oracle fails to disclose, teach, or 
suggest an intelligence module that "removes from the selected transaction document 
information in the sections specific to the past transaction to create the generic document 
capable of being used to facilitate the future transaction"' as recited in Claim 5 as amended. 
In other words, there is no generic document created during the import process disclosed in 
Oracle (or at any other point in Oracle), and no information in the sections specific to the 
past transaction is removed from a selected transaction document (associated with the past 
transaction) to create a generic document capable of being used to facilitate the future 
transaction, as recited in Claim 1. 

Keller fails to make up for these deficiencies of Oracle. 

Third, the proposed Oracle-Keller combination fails to disclose, teach, or suggest an 
intelligence module that "carries forward the generic sections from the selected transaction 
document into the generic document to protect one or more confidential details in the selected 
transaction document," as recited in Claim 5 as amended. The Examiner acknowledges that 
Oracle fails to teach these limitations. Instead, the Examiner argues that Keller discloses 
these limitations. {See Office Action, Page 8) At the portion of Keller on which the Examiner 
relies, Keller merely discloses that a manufacturer can download portions of its own database 
to a transaction server and that at the transaction server, the data can be partitioned and 
protected by security techniques so that there is little risk of unauthorized disclosure of one 
manufacturer's information to another manufacturer. {See Page 2, Paragraph 15 and Office 
Action, Page 8) However, this portion of Keller clearly fails to disclose, teach, or suggest the 
creation of a generic document, let alone an intelligence module that "carries forward the 
generic sections from the selected transaction document [associated with a past transaction 
and selected by a party who was not a party to the past transaction] into the generic document 
[in response to selection of the transaction document by a party who was not a party to the 
past transaction] to protect one or more confidential details in the selected transaction 
document," as recited in Claim 5 as amended. 
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For at least these reasons, Applicant respectfully submits that dependent Claims 5, 16, 
and 24 are clearly allowable over the proposed Oracle-Keller combination. 

As another example, dependent Claim 7, as amended, recites that "the intelligence 
module is further operable to dynamically adjust the information in the sections in the generic 
document to include current information." Dependent Claims 18 and 26 recite analogous 
limitations. The Examiner argues that the EDI Gateway menu shown on Page 5-3 of Oracle 
for navigating the change of interface data files discloses the limitations recited in Claims 7, 
18, and 26. {See Office Action, Page 9) Applicant respectfully disagrees. First, as discussed 
above with reference to independent Claim 1 and dependent Claim 5, Oracle fails to disclose, 
teach, or suggest the creation of any generic document. Second, the cited portion of Oracle 
clearly fails to disclose, teach, or suggest an intelligence module that is further operable to 
"dynamically adjust the information in the sections in the generic document [capable of being 
used to facilitate a future transaction] to include current information," as recited in Claim 7 as 
amended. 

For at least these reasons, Applicant respectfully submits that dependent Claims 7, 18, 
and 26 are clearly allowable over the proposed Oracle-Keller combination. 

For at least these reasons, Applicant respectfully requests reconsideration and 
allowance of dependent Claims 5, 7, 9, 16-18, 24-26, 29-30, 34-35, and 41-42. 

III. No Waiver 

All of Applicant's arguments and amendments are without prejudice or disclaimer. 
Additionally, Applicant has merely discussed example distinctions from the references cited 
by the Examiner. Other distinctions may exist, and Applicant reserves the right to discuss 
these additional distinctions in a future Response or on Appeal, if appropriate. By not 
responding to additional statements made by the Examiner, Applicant does not acquiesce to 
the Examiner's additional statements. The example distinctions discussed by Applicant are 
sufficient to overcome the Examiner's rejections. 
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Conclusion 

Applicant has made an earnest attempt to place this case in condition for allowance. 
For at least the foregoing reasons, Applicant respectfully requests full allowance of all 
pending claims. 

If the Examiner believes a telephone conference would advance prosecution of this 
case in any way, the Examiner is invited to contact Christopher W. Kennedy, Attorney for 
Applicant, at the Examiner's convenience at (214) 953-6812. 

Although Applicant believes no fees are due, the Commissioner is hereby authorized 
to charge any fees or credit any overpayments to Deposit Account No. 02-0384 of Baker 
Botts L.L.P. 



Respectfully submitted, 



BAKER BOTTS L.L.P. 



Attorneys for Applicant 




Chad D. Terrell 
Reg. No. 52,279 



Date: February 3, 2005 



Correspondence Address : 
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